Read the original article here.

---

Okay, let's transform the concept of Pointer Authentication into an educational resource fitting the theme of "The Forbidden Code: Underground Programming Techniques They Won’t Teach You in School." This means focusing on the low-level fight between system security and exploit techniques, positioning Pointer Authentication as a crucial defense mechanism against "forbidden" pointer-based attacks.

---

The Forbidden Code: Understanding Pointer Authentication (PAC)

Welcome to a section of "The Forbidden Code," where we peel back the layers of system security to understand the defenses built against the very techniques some might explore. Today, we delve into Pointer Authentication, a modern hardware-assisted mechanism designed to thwart one of the most potent classes of attacks: those that hijack control flow by manipulating pointers. If you're learning about exploit development or deep system internals, understanding PAC isn't just academic – it's about understanding the modern battlefield.

1. The Problem: Pointers – The Gates to Execution

In the world of low-level programming (like C and C++), pointers are fundamental. They hold memory addresses, serving as keys to data structures, function locations, and critical system information. However, this power makes them a prime target for attackers.

Definition: A Pointer is a variable that stores the memory address of another variable or a function. They are essential for dynamic memory allocation, data structures (like linked lists, trees), and indirect access to data or code.

Many classic vulnerabilities revolve around corrupting pointers stored in memory. Techniques like buffer overflows, use-after-free errors, and format string bugs can allow an attacker to write arbitrary values to memory locations, including locations holding pointers.

The Attack Vector: Hijacking Control Flow

The most devastating use of pointer corruption is hijacking the program's control flow. Instead of just corrupting data, attackers aim to make the program execute code they choose. This is often done by overwriting pointers that determine where the program goes next:

• Return Addresses: Overwriting the return address on the stack makes a function return to an attacker-specified location instead of its legitimate caller.
• Function Pointers: Overwriting pointers to functions stored in data structures or global/static memory redirects function calls.
• Exception Handlers: Diverting execution upon error.
• Jump Tables: Altering pointers used in switch statements or virtual function calls.

Enter ROP and JOP: The Advanced Pointer Attacks

Exploits evolved beyond simply injecting and running new code (which Data Execution Prevention - DEP - largely stopped). Attackers found ways to execute malicious logic using existing code fragments already present in the legitimate program or libraries.

Definition: Return-Oriented Programming (ROP): An exploit technique where an attacker gains control of the call stack to hijack program control flow. The attacker chains together small snippets of code, called "gadgets," that end with a return instruction. Each gadget performs a small operation (e.g., popping values into registers) before returning, effectively allowing the attacker to perform complex operations by "returning" through a sequence of gadgets.

Definition: Jump-Oriented Programming (JOP): Similar to ROP, but gadgets end with an indirect jump or call instruction instead of a return. This technique is often used when ROP is harder due to stack constraints or specific defense mechanisms.

ROP and JOP are incredibly powerful because they don't inject new code; they reuse trusted code. This bypasses traditional defenses like DEP. Their success hinges on the ability to place the addresses of desired gadgets or functions into memory where they will be picked up and executed as if they were legitimate pointers.

This is where Pointer Authentication comes in. It's a direct countermeasure to the attacker's ability to arbitrarily forge valid pointer values.

2. The Solution: Pointer Authentication (PAC)

Pointer Authentication is a security feature, typically implemented in hardware, that adds a cryptographic "seal" or signature to a pointer value. Before a pointer is used (e.g., loaded into an instruction pointer or used to access memory), its signature is checked. If the signature is invalid, it indicates the pointer has likely been tampered with, and the system can prevent its use, often crashing the program safely before malicious code can execute.

Definition: Pointer Authentication Code (PAC): A cryptographic signature or tag generated for a pointer value using a secret key and a context value. The PAC is stored alongside the pointer (often encoded within the pointer value itself or in adjacent memory). It allows the system to verify the pointer's integrity later.

The core idea is that an attacker who corrupts a pointer value typically won't know the secret key or the correct context used to generate the original PAC. Therefore, they cannot generate a valid PAC for their forged pointer value. Any attempt to use the tampered pointer will fail the authentication check.

3. How It Works Under the Hood: Signing and Authenticating

Pointer Authentication involves two main operations:

1. Signing: Generating a PAC for a pointer and associating it with the pointer.
2. Authenticating: Verifying that the PAC associated with a pointer is still valid before the pointer is used.

Let's break down the signing process:

PAC = Sign(Pointer_Value, Key, Context)

• Pointer_Value: The actual memory address the pointer points to.
• Key: A secret, randomly generated key unique to the process or thread. These keys are typically stored in special, inaccessible hardware registers. An attacker cannot read these keys from memory.
• Context: An auxiliary value that helps ensure the PAC is valid only for a specific use of the pointer. This could be related to the pointer's location (e.g., the stack frame address for a return address) or its intended type/purpose. The context prevents an attacker from taking a valid pointer/PAC pair from one location or use case and reusing it elsewhere.
• Sign(...): A hardware instruction that performs a cryptographic operation (often similar to a block cipher or hash function keyed by Key) on the Pointer_Value and Context to produce the PAC.

The resulting PAC is then stored somehow with the Pointer_Value. Since memory is precious and pointers are usually 64 bits on modern systems, the PAC is often encoded directly into the unused high bits of the pointer itself. This is possible because operating systems typically don't use the full 64-bit address space; the top bits are often zero or follow a specific pattern (e.g., sign extension). The PAC calculation is designed such that these normally zero/patterned bits can be overwritten with the PAC without affecting the actual lower address bits.

Now, the authentication process:

Is_Valid = Authenticate(Pointer_With_PAC, Key, Context)

• Pointer_With_PAC: The pointer value as read from memory, which now contains the original Pointer_Value and the encoded PAC in its high bits.
• Key: The same secret key used during signing.
• Context: The same context value used during signing.
• Authenticate(...): A hardware instruction that performs the inverse or verification counterpart of the Sign operation. It reconstructs the expected PAC using the Pointer_Value (extracted from the lower bits of Pointer_With_PAC), the Key, and the Context. It then compares this calculated PAC with the PAC stored in the high bits of Pointer_With_PAC.

If the calculated PAC matches the stored PAC, the function returns the original, unauthenticated Pointer_Value (with the high PAC bits cleared or restored to their expected non-PAC state), and Is_Valid is true. This pointer can then be used safely.

If they don't match, Is_Valid is false, or the hardware instruction might immediately trigger an exception or fault, preventing the tampered pointer from being used.

The Role of Context

The Context is a critical part of PAC's security. Imagine a valid pointer P1 to function A with PAC PAC1. If the context was always zero, an attacker might be able to copy P1 and PAC1 and use them to overwrite a different function pointer P2 that was supposed to point to function B. With a zero context, P1 + PAC1 might authenticate successfully even in the location of P2.

By using a context value tied to the use of the pointer (e.g., the address of the variable storing the pointer, the stack frame pointer for a return address, a value representing the call site), the PAC becomes valid only for that specific context. An attacker trying to reuse P1 + PAC1 in a different context (say, to overwrite P2 with a different context value) will find that Authenticate(P1_with_PAC1, Key, Different_Context) fails.

This makes it much harder for attackers to simply copy valid pointer/PAC pairs from one part of memory or one usage to another.

4. The Lifecycle of an Authenticated Pointer (Example: Return Address)

Let's trace how PAC protects a return address, a prime target for ROP attacks:

1. Function Call: Before FunctionA calls FunctionB, the legitimate return address (the instruction address in FunctionA where execution should resume) is calculated, let's call it ReturnAddr.
2. Signing: The system (compiler-generated code or hardware mechanism) signs ReturnAddr using a per-thread secret key and the current stack frame address (SP) as the context. ReturnAddr_With_PAC = Sign(ReturnAddr, Thread_Key, SP)
3. Storing: ReturnAddr_With_PAC is pushed onto the stack as the return address for FunctionB.
4. Function B Executes: While FunctionB runs, an attacker might try to exploit a vulnerability (like a buffer overflow) to overwrite the stored ReturnAddr_With_PAC on the stack with the address of their first ROP gadget (Gadget1_Addr) plus a forged PAC (Forged_PAC). Stack_Return_Slot now contains Gadget1_Addr_With_Forged_PAC.
5. Function Return: When FunctionB finishes, it attempts to return. It loads the value from the stack's return address slot (Gadget1_Addr_With_Forged_PAC) into a register, say LR (Link Register).
6. Authentication: Before actually jumping to the address in LR, the system (via hardware instructions) authenticates the pointer using the same thread key and the current stack pointer (SP - which should be the same value as when it was signed). Authenticated_Addr = Authenticate(LR, Thread_Key, SP)
7. Verification: The hardware performs the check. Since the attacker didn't know Thread_Key or how to generate a valid PAC for Gadget1_Addr with SP as context, Gadget1_Addr_With_Forged_PAC will fail the authentication check.
8. Result: The Authenticate instruction either clears the register (setting the address to an invalid value like 0) or triggers a fault/exception (e.g., a crash). The program doesn't jump to Gadget1_Addr. The ROP attack is stopped.

If the attacker hadn't tampered with the pointer, Authenticated_Addr would successfully yield the original ReturnAddr, and the program would resume legitimate execution in FunctionA.

5. Why This Works Against Pointer Attacks

PAC effectively raises the bar significantly for pointer-based attacks like ROP and JOP:

• Requires Key Knowledge: An attacker cannot forge a valid PAC for an arbitrary pointer address without knowing the secret authentication key, which is stored in hardware registers inaccessible to software (especially untrusted or exploited software).
• Requires Context Knowledge: Even if an attacker somehow learned a key (extremely unlikely), they would also need to know the correct context value used to sign the pointer they want to overwrite. Contexts tied to stack frames, object addresses, or call sites are difficult for an attacker to predict or control precisely across different parts of the program's execution.
• Difficult to Guess: PACs are generated using cryptographic-quality functions. Guessing a valid PAC for a given pointer and context is computationally infeasible within the attacker's timeframe.
• Atomic Authentication: The authentication check happens via dedicated hardware instructions, often integrated directly into the instructions that use pointers (like return or indirect jump instructions). This makes it very difficult for an attacker to perform a classic Time-of-Check to Time-of-Use (TOCTOU) attack or bypass the check.

6. Implementation Details: Hardware is Key

While software-based pointer protection schemes exist (like Google's CFI, which can use compiler instrumentation), Pointer Authentication is most effective when implemented in hardware.

• ARM Pointer Authentication (ARMv8.3-A and later): ARM is a pioneer in widely adopting hardware PAC. They introduced specific instructions (PACIA, PACDA, AUTIA, AUTDA, etc.) to sign and authenticate code pointers (using keys A and B) and data pointers (using keys C and D). Contexts can be provided via registers. Return address authentication is often handled via dedicated instructions that automatically use the stack pointer as context and a specific key.
• Intel Control-Flow Enforcement Technology (CET): Intel's approach is related but distinct. Its "Indirect Branch Tracking" component validates indirect jumps/calls using markers (ENDBRANCH) placed at valid destinations by the compiler. Its "Shadow Stack" component stores return addresses in a separate, hardware-protected stack, making stack buffer overflow attacks on return addresses ineffective. While not strictly "authenticating the pointer value," Shadow Stack provides a similar protection goal for return addresses against pointer corruption on the main stack. PAC is more general, protecting any pointer type (data, function, return addresses) based on signing the pointer value itself.

Hardware implementations are faster and much harder for attackers to tamper with compared to pure software solutions.

7. Advantages and Limitations

Advantages:

• Strong Security: Provides a powerful, cryptographic defense against pointer corruption and control flow hijacking.
• Granular Protection: Can protect various types of pointers (return addresses, function pointers, data pointers).
• Hardware Speed: Authentication is performed by dedicated hardware, minimizing performance overhead compared to purely software-based checks.
• Hard to Bypass: Relies on secret hardware keys and cryptographic operations, making PAC forgery extremely difficult.

Limitations:

• Performance Overhead: While minimized by hardware, signing and authentication instructions still add some latency. Compilers need to be smart about where to insert these operations.
• Compiler/Toolchain Support: Requires compiler support to insert the necessary signing and authentication instructions and manage contexts.
• Debugging Complexity: Debugging code with PAC can be tricky, as pointer values seen in debuggers might include PACs, and attempting to dereference an unauthenticated pointer can cause crashes.
• Partial Protection: PAC protects against unauthorized modification of pointers but doesn't inherently protect against legitimate but malicious pointer changes (e.g., an attacker controlling input that legitimately changes a pointer value through an application logic flaw, not memory corruption). It also doesn't protect against data corruption or other non-pointer-based attacks.
• Potential Side Channels: Like many security features, theoretical side-channel attacks against PAC implementations might exist, though these are typically much harder to exploit than direct memory corruption.

8. PAC vs. Other Mitigations

PAC is often part of a layered defense strategy:

• Data Execution Prevention (DEP): Prevents code execution from data pages. PAC works alongside DEP by stopping the attacker from pointing execution into unintended code areas in the first place.
• Address Space Layout Randomization (ASLR): Randomizes the base addresses of libraries, executables, and stack/heap. ASLR makes it harder for an attacker to know the exact address of a gadget or function. PAC complements ASLR: even if ASLR is bypassed or an attacker leaks an address, they still can't forge a valid PAC for it.
• Control-Flow Integrity (CFI): A broad term for techniques that ensure program execution follows a legitimate control flow graph. PAC is a form of fine-grained, hardware-assisted CFI, specifically for indirect branches and pointer usage. Other CFI methods might use compiler instrumentation or dynamic analysis.

PAC provides a strong integrity check on the pointer value itself, making it a powerful last line of defense against attacks that rely on crafting fake pointers.

9. Conclusion: Hardening the Gates

Pointer Authentication is a prime example of how system security evolves in direct response to exploit techniques. As attackers got sophisticated with ROP and JOP, hardware vendors and OS developers responded by hardening the very mechanism these attacks target: the pointer itself.

Understanding PAC isn't just about knowing a defense mechanism; it's about appreciating the intricate, low-level battleground of modern system security. It shows how cryptography and careful hardware/software co-design are used to build resilience against the "forbidden code" techniques that manipulate the fundamental building blocks of program execution. It's a necessary concept for anyone looking to truly understand the depths of system programming and security in the 21st century.